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Alexandria, VA 22313-1450 

Dear Sir: 

Applicant requests review of the final rejection in the above-identified application. No 
amendments are being filed with this request. This request is being filed with a Notice of Appeal. 
Applicants are in receipt of the Advisory Action of May 8, 2008. Claims 1-20 are pending in the 
present case. Reconsideration of the present case is earnestly requested in light of the following 
remarks. Please note that for brevity, only the primary arguments directed to the independent 
claims are presented, and that additional arguments, e.g., directed to the subject matter of the 
dependent claims, will be presented if and when the case proceeds to Appeal. The Examiner 
rejected claims 1, 2, 5-10, 13-16 and 19-20 under 35 U.S.C. § 103(a) as being unpatentable over 
Kampe et al. (U.S. Publication 2002/0032883) (hereinafter "Kampe") in view of Raman et al. 
(U.S. Publication 2003/02171 19) (hereinafter "Raman"). The following clear errors are noted in 
the Examiner's rejection. 

First, Applicants note that Kampe is directed towards cluster replication using 
checkpoints and makes no mention of databases (the term "database", which has a specific 
meaning in the art, is found nowhere in Kampe), does not teach the loading of new data into a 
clone database, and uses the well known method of providing continuous updates for checkpoints 
to ensure seamless failover and simply does not relate to the problems addressed or methods 
described by the present claims. The Examiner relies on Raman for teaching the production 
database and databases in general, but there is no indication that the checkpoints of Kampe could 
even be used in such a system and the Examiner's provided reason to combine the reference is no 
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more than hind sight reasoning (which is emphasized by the Examiner's own assertions in the 
present Advisory Action). Further, the Examiner's current interpretation of "new data" is clearly 
devoid of merit and does not take into account the plain meaning of Applicants' claim. Specific 
deficiencies in the Examiner's rejection are addressed below. 

Regarding claim 1, Kampe in view of Raman fails to teach or suggest loading new 
data to the database clone , wherein said loading updates the storage checkpoint, wherein 
the new data is new with respect to the production database . With respect to this feature, the 
Examiner relies on Kampe. First, Applicants note that Kampe teaches a system for maintaining 
replicas of a primary component on nodes (via checkpointing) for achieving high availability in a 
cluster (see paragraph [0013]). Thus, Kampe is particularly directed towards achieving high 
availability of a component (in the case of failover) in a cluster rather than loading new data into 
a production database. For example, in Kampe, paragraph [0064] (which the Examiner relies on 
for switching from the previous file system data of the production database to the storage 
checkpoint to be the file system data for the production database), various failover scenarios are 
discussed where a primary component PCI fails and the checkpoint is used to recreate the last 
consistent state of the primary component (either on the first node or on a second node). Thus, in 
Kampe, checkpoints are used to maintain the current state (or information for recovery) of a 
component on the first node, and are not used to load new data (new with respect to the 
production database) into a production database using a database clone. Said another way, 
Kampe is particularly devoted to loading current state data to the checkpoint. Thus, the 
checkpoint data is either old with respect to the current state (i.e., the checkpoint does not have 
the same data and the data is out of date) or up to date with respect to the current state (i.e., the 
checkpoint and the component have same data). Under no condition is the checkpoint data ever 
new with respect to the current state (i.e., not the same data and the checkpoint has new data that 
is not present in the primary component). Thus, Kampe actually teaches the opposite from this 
limitation as Kampe is devoted to replication of data to a checkpoint rather than loading new data 
into a database clone to update the production database. 

Applicants note that the Examiner specifically cites "(504)" for this limitation without 
any further explanation. 504 is a block in Figure 4A of Kampe which states "continuously update 
checkpoint". Thus, 504 relates to maintaining the checkpoint with respect to the current state of 
the primary component. As argued above, there is no indication in this Figure or anywhere else 
(in Kampe or Raman) which relates to loading new data to the database clone, wherein the new 
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data is new with respect to the production database . Using checkpoints to maintain a current 
state (or backup of a current state) does not relate to loading new information into a database 
clone (or checkpoint) which is new with respect to the production database (or, using the 
Examiner's citation, the primary component of Kampe). Thus, claim 1 relates to loading data, 
which did not previously exist in the production database, into a database clone / checkpoint, and 
then using the file system data of the checkpoint as the file system data of the production database 
(thereby loading the new data into the production database). Neither Kampe nor Raman (singly 
or in combination) teach these features of claim 1. Instead, as indicated above, Kampe maintains 
a current state of the primary component for failover purposes and does not load new information 
with respect to the primary component. As indicated above, Applicants further note that loading 
new data (as recited in Applicants' claims) into the checkpoints of Kampe would be counter to 
the purpose of high availability in a cluster since the replica / checkpoint would no longer 
represent the current state of the primary component. Thus, the cited references do not teach or 
suggest loading new data to the database clone, wherein said load updates the storage 
checkpoint, wherein the new data is new with respect to the production database . 

In response to these arguments, the Examiner cites paragraph [0078] of Kampe and 
describes various data characteristics of the checkpoint of Kampe (e.g., format, states, control 
blocks, and attributes). The Examiner then goes on to assert these data characteristics "must be 
'loaded' as claimed in order to manage the checkpoint". Applicants respectfully submit that this 
checkpoint attribute data does not relate to the loading of new data of the claims. More 
specifically, format data, state data, and control block data clearly do not correspond to "loading 
new data into the checkpoint" and instead are characteristics of the checkpoint itself. Loading 
new data into a database is a specific process that is different than storing checkpoint 
characteristic data, as any one of ordinary skill in the art understands. The claimed limitations 
include generating a database clone which includes a storage checkpoint, loading new data to the 
database clone, which updates a storage checkpoint, which is used after the load as the file system 
data for the production database. Clearly, loading new data is not simply storing characteristic 
data of the checkpoint (as asserted by the Examiner), but is instead new data that is loaded in the 
database and becomes production data. Kampe makes a similar distinction between the 
characteristic data and the actual checkpointing data (see, e.g., paragraph [0085]). Thus, storing 
characteristic data is clearly not the same as loading new data into the database clone, where the 
load updates the storage checkpoint, where the new data is new with respect to the production 
database, and where after the load, the file system data of the checkpoint is used as the file system 
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data of the production database. Furthermore, there is no indication that the checkpoint 
characteristic data cited by the Examiner is actually used after failover, but instead is 
characteristic data of the checkpoint. 

The Examiner goes on to assert that "Kampe also meets the claim limitation when 
interpreting 'new' as 'current', 'recent' or 'fresh'". The Examiner then goes on to refer to 
"continuously updating a checkpoint" and asserts that the continuously updated data "thus 
recently comes into existence during creation/update in steps 503-505, whereas the data in the 
primary component has already existed". Applicants submit that the interpretation of 'new' as 
already existing in the production database is entirely without merit and is inapposite to the plain 
meaning of the claim. Clearly, if the data is the same data that has already existed in the primary 
component, it is not new data with respect to the production database (primary component in the 
Examiner's citation). Applicants further submit that the previously submitted arguments from 
above appear to be ignored in these assertions. 

In the present Advisory Action, the Examiner responds by asserting: 

The word "new" is broadly and reasonably interpreted in this situation as being 
new at least with respect to time. As seen in the prior action, since the prior art 
"continuously updates" the checkpoint, the data in the checkpoint is newer in 
time than the data in the production database at certain times, even if other 
portions of the data may be the same. 

The Examiner's interpretation goes beyond reasonably broad and stands the plain 
meaning on its head. As already noted above, the data of the checkpoint can never be "new 
data" with respect to the primary component as it is used to back up the primary component, and 
is indeed a 'replica' of the primary component. One of skill in the art understands that replicas 
and backups of data do not include new information or data, and if they did, would render the 
system described in Kampe inoperable. The fact that the data is copied at a later in point in time 
does not make that data new - the data is still the same data, and is, at best, current data with 
respect to the primary component. With even a cursory reading of Applicants' claims or 
specification, one of skill in the art would never interpret new data as currently interpreted by the 
Examiner. 

Furthermore, the Examiner has failed to provide a proper reason to combine to the 
two references. In the instant Office Action, the Examiner asserts it would have been obvious to 
modify Kampe, "to improve accessibility for file system data, as known to one of ordinary skill in 
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the art and taught by Raman (para. 0049)". The Examiner has not provided any reason to make 
the specific combination and instead has merely provided a portion of Raman which describes a 
method for providing copies of consistent file systems with concurrent read-write updating of the 
file system. There is no indication in this section (or in the Examiner's provided motivation) as to 
why the maintaining of file systems as taught by Raman applies to the "primary component" of 
Kampe. More specifically, the cited portion does not relate to a "production database", the 
accessibility of a production database during the load of new data, or any reason to include such 
features in Kampe as alleged by the Examiner. Instead, Raman teaches that updates may be made 
over an IP network, and that concurrent read-only access to the remote copies is available. 

In the present Advisory Action, the Examiner asserts "It should be noted that the 
combination was made so that the production database would be available during the load". 
Applicants respectfully submit that making a combination for the sole purpose of teaching a 
claimed limitation is the definition of hindsight reasoning. Additionally, adding a reference only 
to add a specific teaching is not a reason to combine the references in the first place. The 
Examiner reiterates that improving accessibility for a file system data is a motivation; however, 
this only identifies the presumed result of the combination and does not identify any particular 
reason for one of skill in the art to combine the references. Thus, the Examiner's provided reason 
to combine the references is improper and based on hindsight reasoning. 

Applicants submit the application is in condition for allowance, and notice to that effect 
is respectfully requested. If any fees are due, the Commissioner is authorized to charge said fees 
to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5760- 
12400/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Applicants 

Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: May 28, 2008 
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